In the process of software development, a developer composes source code with respect to a function to be achieved by software, and then a tester utilizes test cases to test the software that is built from the source code. Generally, the composing of the source code is completed step-by-step. The developer(s) (generally many developers for large-scale software) continually submit change tracks to the source code, so as to change, supplement and complete the source code. Then, there exists such a case where software built from a certain version of the source code may pass the test by test cases, but software, with several change tracks being added, cannot run properly and fails to pass the test by the same test cases. This phenomenon is named as software regression. In order to eliminate software regression, the developer needs to find out the change track causing software regression, and this is named as regression identification. The change track causing software regression is usually named as a defective change track.
A plurality of ways are used in the prior art to identify a defective change track, that is, to perform regression identification. In one solution, a test is performed in turn for a plurality of added change tracks. If software can pass the test at a certain change track i but cannot pass the test at the next change track (i+1), then the place of the change track (i+1) can be identified as a regression point, and the change track (i+1) can be identified as a defective change track. The solution can be combined with dichotomy to improve identification efficiency. For example, for n change tracks, the test starts from the place of n/2. If the test passes at the place of n/2, then the test is further performed at the intermediate between n/2 and n; if the test does not pass at the place of 2/n, then the test is further performed at the intermediate between the change track 1 and change track n/2, until the defective track defined hereinabove is identified. In such a solution, time spent by regression identification relies on the number n of change tracks, time b spent by each build and time t spent by test. On average, time spent for identifying a regression point is n/2*(b+t). For development and test of large-scale software, b and t may be very large, whereby such an identification process will take a very long time.
In another solution, each time a change track is submitted, software is re-built and tested. If software cannot pass the test by test cases, the newly added change track will be judged as a defective change track. Such a solution may easily determine a regression point. However, this solution increases the frequency of build and test significantly. For the development of some large-scale software, build and test with high frequency is unrealistic.
In addition to consuming more time and effort, the above solutions may determine the regression point, but cannot provide more detailed information so as to provide suggestions to developers as to debugging and error correction.